home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1618.txt < prev    next >
Text File  |  1994-08-01  |  15KB  |  445 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Simpson
  8. Request for Comments: 1618                                    Daydreamer
  9. Category: Standards Track                                       May 1994
  10.  
  11.  
  12.                              PPP over ISDN
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24.  
  25. Abstract
  26.  
  27.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  28.    transporting multi-protocol datagrams over point-to-point links.
  29.    This document describes the use of PPP over Integrated Services
  30.    Digital Network (ISDN) switched circuits.
  31.  
  32.    This document is the product of the Point-to-Point Protocol Working
  33.    Group of the Internet Engineering Task Force (IETF).  Comments should
  34.    be submitted to the ietf-ppp@merit.edu mailing list.
  35.  
  36.  
  37. Applicability
  38.  
  39.    This specification is intended for those implementations which desire
  40.    to use the PPP encapsulation over ISDN point-to-point links.  PPP is
  41.    not designed for multi-point or multi-access environments.
  42.  
  43.    "It is clear that there is never likely to be a single, monolithic,
  44.    worldwide ISDN." [3] The goal of this document is to describe a few
  45.    common implementations, chosen from the current wide variety of
  46.    alternatives, in an effort to promote interoperability.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                                                         [Page i]
  59. RFC 1618                     PPP over ISDN                      May 1994
  60.  
  61.  
  62.                            Table of Contents
  63.  
  64.  
  65.      1.     Introduction ..........................................    1
  66.  
  67.      2.     Physical Layer Requirements ...........................    1
  68.  
  69.      3.     Framing ...............................................    3
  70.  
  71.      4.     Out-of-Band signaling .................................    4
  72.  
  73.      5.     Configuration Details .................................    5
  74.  
  75.      SECURITY CONSIDERATIONS ......................................    5
  76.  
  77.      REFERENCES ...................................................    5
  78.  
  79.      ACKNOWLEDGEMENTS .............................................    6
  80.  
  81.      CHAIR'S ADDRESS ..............................................    6
  82.  
  83.      AUTHOR'S ADDRESS .............................................    6
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Simpson                                                         [Page ii]
  113. RFC 1618                     PPP over ISDN                      May 1994
  114.  
  115.  
  116. 1.  Introduction
  117.  
  118.    PPP was designed as a standard method of communicating over point-
  119.    to-point links.  Initial deployment has been over short local lines,
  120.    leased lines, and plain-old-telephone-service (POTS) using modems.
  121.    As new packet services and higher speed lines are introduced, PPP is
  122.    easily deployed in these environments as well.
  123.  
  124.    This specification is primarily concerned with the use of the PPP
  125.    encapsulation over ISDN links.  Since the ISDN B-channel is by
  126.    definition a point-to-point circuit, PPP is well suited to use over
  127.    these links.
  128.  
  129.    The ISDN Primary Rate Interface (PRI) may support many concurrent B-
  130.    channel links.  The PPP LCP and NCP mechanisms are particularly
  131.    useful in this situation in reducing or eliminating hand
  132.    configuration, and facilitating ease of communication between diverse
  133.    implementations.
  134.  
  135.    The ISDN D-channel can also be used for sending PPP packets when
  136.    suitably framed, but is limited in bandwidth and often restricts
  137.    communication links to a local switch.
  138.  
  139.    The terminology of ISDN can be confusing.  Here is a simple graphical
  140.    representation of the points used in subsequent descriptions:
  141.  
  142.                    +-------+     +-------+     +-------+
  143.                R   |       |  S  |       |  T  |       |   U
  144.                +---+  TA   +--+--+  NT2  +--+--+  NT1  +---+
  145.                    |       |     |       |     |       |
  146.                    +-------+     +-------+     +-------+
  147.  
  148.    These elements are frequently combined into a single device.
  149.  
  150.  
  151.  
  152. 2.  Physical Layer Requirements
  153.  
  154.    PPP treats ISDN channels as bit or octet oriented synchronous links.
  155.    These links MUST be full-duplex, but MAY be either dedicated or
  156.    circuit-switched.
  157.  
  158.    Interface Format
  159.  
  160.       PPP presents an octet interface to the physical layer.  There is
  161.       no provision for sub-octets to be supplied or accepted.  The octet
  162.       stream is applied primarily at the R or T reference points.
  163.  
  164.  
  165.  
  166.  
  167. Simpson                                                         [Page 1]
  168. RFC 1618                     PPP over ISDN                      May 1994
  169.  
  170.  
  171.    Transmission Rate
  172.  
  173.       PPP does not impose any restrictions regarding transmission rate,
  174.       other than that of the particular ISDN channel interface.
  175.  
  176.    Control Signals
  177.  
  178.       PPP does not require the use of control signals.  When available,
  179.       using such signals can allow greater functionality and
  180.       performance.  Implications are discussed in [2].
  181.  
  182.       Control signals MAY be required by some of the framing techniques
  183.       described, and is outside the scope of this specification.
  184.  
  185.    Encoding
  186.  
  187.       The definition of various encodings and scrambling is the
  188.       responsibility of the DTE/DCE equipment in use, and is outside the
  189.       scope of this specification.
  190.  
  191.       While PPP will operate without regard to the underlying
  192.       representation of the bit stream, lack of standards for
  193.       transmission will hinder interoperability as surely as lack of
  194.       data link standards.  The D-channel LAPD interface requires NRZ
  195.       encoding at the T reference point.  Therefore, as a default, it is
  196.       recommended that NRZ be used over the B-channel interface at the T
  197.       reference point.  This will allow frames to be easily exchanged
  198.       between the B and D channels.
  199.  
  200.       When configuration of the encoding is allowed, NRZI is recommended
  201.       as an alternative in order to ensure a minimum ones density where
  202.       required over the clear B-channel, with caveats regarding FCS [2].
  203.  
  204.       Historically, some implementations have used Inverted NRZ (merely
  205.       switching the sense of mark and space), in order to ensure a
  206.       minimum ones density with bit-synchronous HDLC.  The use of
  207.       Inverted NRZ is deprecated.
  208.  
  209.       Automatic Detection
  210.  
  211.          Implementations which desire to interoperate with multiple
  212.          encodings MAY choose to detect those encodings automatically.
  213.          Automatic encoding detection is particularly important for
  214.          Primary Rate Interfaces, to avoid extensive pre-configuration.
  215.          Only simple encodings are currently distinguished.
  216.  
  217.          The only reliable method of detection available is to switch
  218.          modes between the supported encodings.  Transmission of the LCP
  219.  
  220.  
  221.  
  222. Simpson                                                         [Page 2]
  223. RFC 1618                     PPP over ISDN                      May 1994
  224.  
  225.  
  226.          Configure-Request SHOULD be tried twice for each mode before
  227.          switching in rotation.  This ensures that sufficient time is
  228.          available for a response to arrive from the peer.
  229.  
  230.          Max-Configure MUST be set such that the cumulative attempts
  231.          result in no more than 59 seconds of time before disconnect.
  232.          It is preferable that the usual limit of 30 seconds be
  233.          observed.
  234.  
  235.       Prior Configuration
  236.  
  237.          By prior configuration, PPP MAY also be used with other
  238.          encodings.  Because of difficulty distinguishing them, it is
  239.          not recommended that these encodings be automatically detected.
  240.  
  241.          Terminal adapters conforming to V.120 [4] can be used as a
  242.          simple interface to workstations.  Asynchronous HDLC framing
  243.          [2] is accepted at the R reference point.  The terminal adapter
  244.          provides async-sync conversion.  Multiple B-channels can be
  245.          used in parallel.  Unfortunately, V.120 has a framing mode of
  246.          its own for rate adaptation, which is difficult to distinguish
  247.          from Frame Relay, and which can confuse in-band frame
  248.          detection.  V.120 is not interoperable with bit-synchronous
  249.          links, since V.120 does not provide octet-stuffing to bit-
  250.          stuffing conversion.  Therefore, V.120 is deprecated in favor
  251.          of more modern standards, such as "PPP in Frame Relay".
  252.  
  253.          The "Bandwidth On Demand Interoperability Group" has defined a
  254.          proposal called BONDING.  Multiple B-channels can be used in
  255.          parallel.  BONDING has an initialization period of its own,
  256.          which might conflict with the simple detection technique
  257.          described above, and requires extensive individual
  258.          configuration in some current implementations when multiple B-
  259.          channels are involved.  It is recommended that the PPP Multi-
  260.          Link Procedure be used instead of BONDING.
  261.  
  262.  
  263.  
  264. 3.  Framing
  265.  
  266.    For B-channels, in the absence of prior configuration, the
  267.    implementation MUST first use bit-synchronous HDLC [2], as opposed to
  268.    other framings, for initial link establishment.  This assumes that
  269.    circuit-switched communications are generally [host | router] to
  270.    [host | router].
  271.  
  272.    By prior configuration, octet-synchronous HDLC [2] is recommended
  273.    where the network termination equipment interfaces directly to the T
  274.  
  275.  
  276.  
  277. Simpson                                                         [Page 3]
  278. RFC 1618                     PPP over ISDN                    May 1994
  279.  
  280.  
  281.    reference point, and octet boundaries are available at the time of
  282.    framing.  Such equipment is likely to be highly integrated, and the
  283.    elimination of bit-synchronous hardware can reduce the part count,
  284.    resulting in lower cost interfaces and simpler configuration.
  285.    Octet-synchronous HDLC MUST be used with NRZ bit encoding.
  286.  
  287.    For D-channels, by default no data service is expected.  By prior
  288.    configuration, "PPP in X.25" or "PPP in Frame Relay" framing MAY be
  289.    used.
  290.  
  291.    Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally
  292.    distinguishable, multiple methods of framing SHOULD NOT be used
  293.    concurrently on the same ISDN channel.  There is no requirement that
  294.    PPP recognize alternative framing techniques, or switch between
  295.    framing techniques without specific configuration.
  296.  
  297.  
  298.  
  299. 4.  Out-of-Band signaling
  300.  
  301.    Experience has shown that the LLC Information Element is not reliably
  302.    transmitted end to end.  The deployment of compatible switches is too
  303.    limited, and the subscription policies of the providers are too
  304.    diverse.  Therefore, transmission of the LLC-IE SHOULD NOT be relied
  305.    upon for framing or encoding determination.
  306.  
  307.    No LLC-IE values which pertain to PPP have been assigned.  Any other
  308.    values which are received are not valid for PPP links, and can be
  309.    ignored for PPP service.
  310.  
  311.    As an alternative administrative measure, multiple directory numbers
  312.    can point to the same physical access facility, by binding particular
  313.    services to each directory number.  The called party identifier has
  314.    proven to be reliably provided by the local switch.
  315.  
  316.    When a called party identifier is used, or when a future LLC-IE value
  317.    is assigned to PPP and the PPP value is received, if the LCP has not
  318.    had the administrative Open event, the call MUST be rejected.
  319.    Receivers MUST NOT accept an incoming call, only to close the circuit
  320.    or ignore packets from the circuit.
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332. Simpson                                                         [Page 4]
  333. RFC 1618                     PPP over ISDN                      May 1994
  334.  
  335.  
  336. 5.  Configuration Details
  337.  
  338.    The LCP recommended sync configuration options apply to ISDN links.
  339.  
  340.    The standard LCP sync configuration defaults apply to ISDN links.
  341.  
  342.    The typical network feeding the link is likely to have a MRU of
  343.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  344.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  345.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  346.    negotiated.
  347.  
  348.    Instead of a constant value for the Restart timer, the exponential
  349.    backoff method is recommended.  The Restart Timer SHOULD be 250
  350.    milliseconds for the initial value, and 3 seconds for the final
  351.    value.
  352.  
  353.    Implementations that include persistent dialing features, such as
  354.    "demand dialing" or "redialing", SHOULD use mechanisms to limit their
  355.    persistence.  Examples of such mechanisms include exponential
  356.    backoff, and discarding packet queues after failure to complete link
  357.    establishment.  In some implementations, discarding the transmit
  358.    queue can temporarily remove the stimulus to retry the connection.
  359.  
  360.  
  361.  
  362. Security Considerations
  363.  
  364.    Security issues are not discussed in this memo.
  365.  
  366.  
  367.  
  368. References
  369.  
  370.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
  371.          1548, Daydreamer, December 1993.
  372.  
  373.    [2]   Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, 
  374.          Daydreamer, December 1993.
  375.  
  376.    [3]   Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan,
  377.          1992.
  378.  
  379.    [4]   CCITT Recommendations I.465 and V.120, "Data Terminal Equipment
  380.          Communications over the Telephone Network with Provision for
  381.          Statistical Multiplexing", CCITT Blue Book, Volume VIII,
  382.          Fascicle VIII.1, 1988.
  383.  
  384.  
  385.  
  386.  
  387. Simpson                                                         [Page 5]
  388. RFC 1618                     PPP over ISDN                      May 1994
  389.  
  390.  
  391. Acknowledgments
  392.  
  393.    This design was inspired by previous drafts of C. Frost, B. Gorsline,
  394.    D. Leifer, K. Muramaki, S. Sheldon, K. Sklower, and T. Sugawara.
  395.  
  396.    Thanks to Oliver Korfmacher (NetCS) for European considerations, Dory
  397.    Leifer (University of Michigan) for technical details and called
  398.    party signalling, and Vernon Schryver (Silicon Graphics) regarding
  399.    handling of link misconfiguration and timeouts.
  400.  
  401.    Special thanks to Morning Star Technologies for providing computing
  402.    resources and network access support for writing this specification.
  403.  
  404.  
  405.  
  406. Chair's Address
  407.  
  408.    The working group can be contacted via the current chair:
  409.  
  410.       Fred Baker
  411.       Advanced Computer Communications
  412.       315 Bollay Drive
  413.       Santa Barbara, California  93117
  414.  
  415.       EMail: fbaker@acc.com
  416.  
  417.  
  418. Author's Address
  419.  
  420.    Questions about this memo can also be directed to:
  421.  
  422.       William Allen Simpson
  423.       Daydreamer
  424.       Computer Systems Consulting Services
  425.       1384 Fontaine
  426.       Madison Heights, Michigan  48071
  427.  
  428.       EMail: Bill.Simpson@um.cc.umich.edu
  429.              bsimpson@MorningStar.com
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442. Simpson                                                         [Page 6]
  443.  
  444.  
  445.